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Foreword 



rd , 



The present document has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



eCall refers to an interoperable in-vehicle emergency call service which is envisioned to be introduced and operated 
across Europe in 2014. According to reports from the European Commission, it is foreseen that eCall will be offered on 
all new vehicles in the EU by 2014. 

The European Commission has brought together standardization bodies, the automotive industry, mobile 
telecommunication industry, public emergency authorities and others in the eSafety Forum initiative which has 
identified high-level requirements, recommendations and guidelines for this eCall service [9] and [10]. The eSafety 
Forum has assigned ETSI MSG to standardize those parts of the eCall service that affect the mobile communication 
system. The development of the eCall standard has been further delegated to the 3"* Generation Partnership Project 
(3GPP). 
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Scope 



The present document specifies the eCall In-band Modem, which is used for reliable transmission of the eCall 
Minimum Set of Data (MSD) from an In-Vehicle System (IVS) to the Public Safety Answering Point (PSAP) via the 
voice channel of cellular and PSTN networks. 

The European Union eCall requirements, recommendations and guidelines were developed by eSafety Forum [10] and 
[11], with important additional work produced by ETSI MSG, GSME, 3GPP, and CEN. 

Previous work in 3GPP TR 22.967 [3] "Transfer of Emergency Call Data", examined the issues associated with the 
transmission of emergency call data from a vehicle to a PSAP. This analysis identified that the preferred option be 
based on an in-band modem solution. 

eCall provides reliable full-duplex data communications between IVS and PSAP in addition to emergency voice call 
(El 12) via the cellular network, and can be initiated either automatically or manually [1]. The eCall In-band Modem 
uses the same voice channel as used for the emergency voice call. eCall allows reliable transmission of MSD alternating 
with a speech conversation through the existing voice communication paths in cellular mobile phone systems. The 
expected benefit is that emergency services will be made aware of accidents much more rapidly, will get precise 
information on location, vehicle type etc. and therefore will be able to reach accident victims faster, with the potential to 
save many lives annually. 

The eCall in-band modem solution described here exceeds the eCall requirements (see Annex A) by means of a 
combination of innovations in data modulation scheme, synchronization, forward error correction coding, hybrid ARQ 
(HARQ) and incremental redundancy transmission. 

The present document provides a general overview and algorithm description of the eCall in-band modems, including 
IVS modem and PSAP modem, to form the complete full-duplex transmission. 

The eCall in-band modems (IVS and PSAP) are fully specified by this TS together with the C-code reference as 
provided in 3GPP TS 26.268 [2]. 

3GPP TS 26.269 [13] deals with the conformance testing for eCall modem implementations, and 3GPP TR 26.969 [14] 
contains a characterization report of the in-band modem. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

eCall: A manually or automatically initiated emergency call (TS12) from a vehicle, supplemented with a minimum set 
of emergency related data (MSD), as defined under the EU Commission"s eSafety initiative. 

eCall In-band Modem: Modem pair (consisting of transmitters and receivers at IVS and PS AP) that operates full- 
duplex and allows reliable transmission of eCall Minimum Set of Data from IVS to PSAP via the voice channel of the 
emergency voice call through cellular and PSTN networks. 

eSafety: European Commission sponsored forum to improve safety aspects of European citizens. 

feedback frame: Downlink signal transmission interval containing feedback data - corresponds to a time interval of 
140 ms or 1 120 samples at an 8 kHz sampling rate. 

frame (or: speech frame): Time interval equal to 20 ms (corresponding to one AMR or FR speech frame, represented 
by 160 samples at an 8 kHz sampling rate). 

MSD: The Minimum Set of Data forming the data component of an eCall sent from a vehicle to a Public Safety 
Answering Point or other designated emergency call centre. The MSD has a maximum size of 140 bytes and includes, 
for example, vehicle identity, location information and time-stamp. 

MSD data frame: Uplink signal transmission interval containing the data of one MSD (after synchronization has been 
established) - corresponds to a time interval of 1320 ms or 10560 samples (fast modulator) and 2 320 ms or 18560 
samples (robust modulator) assuming an 8 kHz sampling rate. 

modulation frame: Symbol transmission time interval equal to 2 ms corresponding to 16 samples at 8 kHz sampling 
rate (fast modulator), or 4 ms corresponding to 32 samples at 8 kHz sampling rate (robust modulator). 

synchronization frame: Signal transmission interval containing synchronization information - corresponds to a time 
interval of 260 ms or 2 080 samples at an 8 kHz sampling rate. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. 

ACK ACKnowledgement 

AMR Adaptive Multi-Rate (speech codec) 
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BCH Bose-Chaudhuri-Hocquenghem (Code) 

BP Band Pass 

CRC Cyclic Redundancy Check 

CTM Cellular Text telephone Modem 

elM eCall In-band Modem 

EU European Union 

EEC Forward Error Correction 

FR Eull Rate (speech codec) 

GSM Global System for Mobile communications 

HARQ Hybrid Automatic Repeat-reQuest 

IR Incremental Redundancy 

IVS In-Vehicle System 

LP Low Pass 

MSD Minimum Set of Data 

NACK Negative ACKnowledgement 

PCCC Parallel Concatenated Convolutional Code 

PCM Pulse Code Modulation 

PSAP Public Safety Answering Point 

PSTN Public Switched Telephone Network 

ROM Read Only Memory 

RV Redundancy Version 

SF Synchronization Frame 

UMTS Universal Mobile Telecommunications Systems 

VAD Voice Activity Detection 



4 General overview 

4.1 eCall system overview 

The eCall system overview is depicted in Figure 1. 
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Figure 1 : eCall system overview [11] 

In the event of a vehicle collision, the eCall in-band modem solution is used in an automatically or manually established 
emergency voice call (El 12) from the vehicle (IVS) via the cellular network to the local emergency agencies, i.e. the 
PSAP. The eCall modem allows to transfer a data message from the IVS over the cellular network to the PSAP which is 
denoted as eCall MSD. The MSD can include, e.g. vehicle location information, time stamp, number of passengers. 
Vehicle Identification Number (VIN), and other relevant accident information. 

It is expected that the eCall MSD information will be sent either immediately following the establishment of the voice 
call or at any point later during the voice call. The integrity of the eCall data sent from the vehicle to the PSAP is 
ensured by the specified modem. 

eCall is a European regional requirement. It shall not have an impact on the global circulation of terminals. 
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4.2 eCall system requirements 



The eCall service requirements have been defined in 3GPP TS 22.101 [1], and are reproduced here for information. Not 
all of the requirements apply to the eCall modem specification in this document. 

The data may be sent prior to, in parallel with, or at the start of the voice component of an emergency call. 

Should the PSAP request additional data then this may be possible during the established emergency call. 

The realisation of the transfer of data during an emergency call shall minimise changes to the originating and 
transit networks. 

Both the voice and data components of the emergency call shall be routed to the same PSAP or designated 
emergency call centre. 

The transmission of the data shall be acknowledged and if necessary data shall be retransmitted. 

A UE configured only to transfer data during emergency calls (e.g. eCall only UE) shall not generate signalling 
to the network besides what is needed to place an emergency call. 

The UE shall indicate at call setup if the emergency call will carry supplementary data. 

The following specific requirements are considered necessary for the satisfactory operation of the eCall service. 
Additionally, all existing TS12 emergency call requirements shall apply. 

An eCall shall consist of a TS 12 emergency call supplemented by a minimum set of emergency related data 
(MSD). 

An eCall may be initiated automatically, for example due to a vehicle collision, or manually by the vehicle 
occupants. 

An IVS, or other UE designed to support eCall functionality, shall include in the emergency call set-up an 
indication that the present call is either a Manually Initiated eCall (MleC) or an Automatically Initiated eCall 
(AleC). 

The Minimum Set of Data (MSD) sent by the In vehicle System (IVS) to the network shall not exceed 140 bytes. 

The MSD should typically be made available to the PSAP within 4 seconds, measured from the time when end 
to end connection with the PSAP is established. 

Should the MSD component not be included in an eCall, or is corrupted or lost for any reason, then this shall not 
affect the associated TS12 emergency call speech functionality. 

A call progress indication shall be provided to the user whilst the MSD transmission is in progress. 

To reduce the time taken to establish an eCall an IVS whilst in eCall only mode, may receive network 
availability information whilst not registered on a PLMN. 

Optionally, PLMNs may make use of eCall indicators, received in the emergency call set-up, to differentiate 
eCalls from other TS12 emergency calls. 

The MleC and AleC may be used to filter or route eCalls to a dedicated PSAP operators. 

Throughout the duration of the emergency call and following receipt of the MSD by the PSAP 

It shall be possible for the PSAP to send a confirmation to the IVS that the MSD has been acted upon. 

It shall be possible for the PSAP to request the IVS to re-send its most recent MSD. 

It shall be possible for the PSAP to instruct the IVS to terminate the eCall. 

For the purpose of selecting the best performing elM solution, these service requirements have been further clarified, 
and performance objectives under different radio channel conditions as well as design constraints are defined in 
Annex A. 
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4.3 



eCall in-band modem architecture 



It is a challenging task to transmit data over the mobile voice channel as required of an in-band modem since speech 
codecs used in digital cellular systems are optimized explicitly for speech signal compression. Therefore, modem 
signals may incur heavy distortion after passing through the effective transmission channel consisting of speech codec, 
possible degradations on the radio channel, and speech decoder with error concealment. Furthermore, in digital cellular 
communications frame losses occur regularly and increase the burden of data recovery by the in-band modem. 

CTM was developed in 3GPP for transmitting text data for text telephony. It was evaluated as a potential solution for 
elM in the technical report (3GPP TR 26.967 [4]) and found not able to meet eCall requirements. 

The present elM solution consists of an IVS data modem and a PSAP data modem, employing signals that have been 
designed to pass through modern speech codecs with only moderate distortion, yet providing sufficiently high data rates 
for quick MSD transmission. 

The overall cellular system architecture, including the IVS and PSAP data modems, is given for information in a 
simpUfied diagram in Figure 2. 

After an emergency voice call has been (automatically or manually) established, the IVS modem receiver constantly 
monitors the incoming signal from the speech decoder output. When prompted by a request from the PSAP operator for 
MSD, the IVS connects the IVS data modem transmitter to the input of the speech coder and mutes any speech from the 
motorist for the duration of MSD transmission to prevent it from interfering with the eCall data transmission. 
Alternatively, it can be the IVS that may trigger the MSD transmission. In this case, the IVS asks the PSAP to request 
an MSD transmission. 

The first operation mode shall be referred to as the pull mode whereas the latter one is the push mode. Essentially, push 
mode is realized by a request from the IVS to the PSAP to pull the MSD. 

The requirement about the modem to be configured in eithsT push or pull mode is beyond the scope of this specification. 
Refer to clause 4.2 for a reproduction of eCall service requirements. 

In general, the mircophone has to be detached from the signal path whenever the eCall modem is actively transmitting. 

The operational principles of the IVS and PSAP modems within the environment illustrated in Figure 1 are further 
explained in the following. Details of the employed algorithms and functions are given in clauses 5 and 6. 
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Figure 2: eCall system within the cellular system architecture 
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4.3.1 Principle operation of tine IVS data modem 

The main components of the IVS data modem are illustrated in Figure 3. The MSD information input into the IVS 
transmitter is first appended with CRC information. These bits are then encoded in the hybrid ARQ (HARQ) encoder 
using FEC coding to reduce the susceptibility to transmission errors. The HARQ encoder employs a powerful state-of- 
the-art turbo encoding scheme with incremental redundancy added for each retransmission. The signal modulator 
converts the encoded data into waveform symbols which are especially suitable for transmission through speech codecs 
employed in present mobile systems, including the GSM Full-Rate (3GPP TS 46.001 [5]) and the various modes of 
AMR codecs (3GPP TS 26.071 [7]). 

The IVS receiver continues to monitor the feedback messages from the PSAP data modem. As long as the received 
feedback messages are NACK messages, retransmissions of the MSD with incremental redundancy are automatically 
continued until a sufficient number of link-layer ACK or higher-layer ACK messages has been received by the IVS, or 
operation is terminated by the PSAP. After the transmission of the MSD information and the ACK messages is 
completed, the eCall modem transmitters in both the IVS and PSAP return to idle state and the signal paths from the 
transmitters are switched off to avoid interference with the normal voice call. 

In push mode, the IVS reuses the downlink message format for requesting the PSAP to pull the MSD. Request 
messages are transmitted until the IVS receiver detects START messages from the PSAP or a timeout occurs. Upon 
detection of the START messages the IVS continues as if it was in pull mode. 

This document only specifies the eCall modem for the transmission of one MSD of length 140 bytes. Messages shorter 
than 140 bytes are assumed to have been padded, e.g., with zeros before being fed to the IVS transmitter. Longer 
message lengths would require a packet segmentation mechanism as well as adaptations to the transmission protocol, 
which are out of scope for this document. 
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Figure 3: eCall IVS data modem overview 

4.3.2 Principle operation of the PSAP data modem 

The main components of the PSAP data modem are illustrated in Figure 4. After having triggered the IVS data modem 
for transmission of MSD, the eCall PSAP receiver continuously monitors the incoming signal from the PSTN. When 
the eCall data signal is detected and synchronized, the signal demodulator demodulates the incoming data symbols. The 
HARQ decoder soft-combines the first MSD transmission with any retransmissions of the information and decodes the 
FEC to determine the information bits, i.e. its estimate of the CRC protected MSD information. If a CRC error is 
detected in the decoded MSD, the PSAP receiver returns NACK and thereby prompts the IVS transmitter to provide 
retransmissions with incremental redundancy. Otherwise, the MSD information is provided to the PSAP operator and 
the IVS transmitter is notified with link-layer or higher-layer ACK messages that retransmissions are no longer 
required. 

In push mode, the PSAP monitors the received signal for a trigger from the IVS. Upon detection of a trigger it transmits 
a request for MSD transmission as it would do in pull mode and continues as described above. 
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The outgoing speech path is switched off when the PS AP transmitter needs to use the voice channel for feedback 
messages. Once the MSD is correctly received and the ACK messages are transmitted, the speech path is unmuted to 
avoid interference with the normal voice call. 
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Figure 4: eCall PSAP data modem overview 



5 Functional description of the IVS data modem 

This clause describes the different functions of the IVS data modem. 



5.1 



IVS transmitter 



The IVS transmitter modulates the MSD data to generate signals suitable for transmission over the in-band voice 
channel to the PSAP. The different blocks of the IVS transmitter are shown in Figure 5. 
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Figure 5: IVS transmitter block diagram 



5.1.1 MSD Message 

The MSD is represented by a field of 140 bytes (1 120 bits). 
The MSD is denoted a,-, ; =1, •••,1120 . 
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5.1.2 CRCcode 

Each MSD message is appended by a field of 28 bit CRC code prior to HARQ FEC encoding. 

The entire MSD of length K= 1 120 bits is used to calculate the CRC parity bits. The length of the CRC protected code 
word isN= 1 148. Then N- K=2S denotes the degree of the generator polynomial. 

The parity bits are generated by the following cyclic generator polynomial: 

8cRC2&(D) = D^^ + D^^ + D^^ + D^^ + D'** + D" + D"" + D'^ + D'"^ + D" + D*^ + D^ + D^ + 1 
Denote the bits in the MSD by a^,a2,----,ai^ and the parity bits by p^,p2,....,P2i- 
The encoding is performed in a systematic form, which means that in GF(2), the polynomial 
fljD'^"^ ^ +^2^^"^ +... + a^D + p^D ^ + P2D +... + p2jD + jc»28 
yields a remainder equal to when divided by gcRcisiD). 

5.1 .3 HARQ FEC encoder 

HARQ FEC encoding includes bit scrambling, turbo coding, and the HARQ scheme. 

5.1.3.1 Bit scrambling 

Bit scrambling is applied to the CRC appended MSD prior to turbo encoding: 
a,(i) = fl„,(/) XOR fo_(/), / = 0,...,1147 

Where a^^^ is the MSD and CRC bitstream, and b^^^ is the scrambling sequence. 

5.1.3.2 Turbo Coding 

The native scheme of the deployed Turbo encoder is a Parallel Concatenated Convolutional Code (PCCC) with two 
identical 8-state constituent encoders with the polynominal 

goiD)=gi(D)=l+D'+D\ 

and one Turbo code internal interleaver. The resulting coding rate of the Turbo coder is r = 1/3. The structure of the 
Turbo coder is illustrated in Figure 6. The initial value of the shift registers of the 8-state constituent encoders are set to 
zeros prior to encoding the MSD. The bits output from the Turbo code internal interleaver are to be input to the second 
8-state constituent encoder. 
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Figure 6: Structure of a rate 1/3 Turbo coder (*1 : dotted lines apply for trellis termination only) 

Trellis termination is performed by taking the tail bits from the shift register feedback after all information bits are 
encoded. Tail bits are padded after the encoding of information bits. The first three tail bits are used to terminate the 
first constituent encoder (upper switch in Figure 6 in lower position) while the second constituent encoder is disabled. 
The last three tail bits are used to terminate the second constituent encoder (lower switch in Figure 6 in lower position) 
while the first constituent encoder is disabled. 

The Turbo code internal interleaver consists of bits-input to a rectangular matrix with padding, intra-row and inter-row 
permutations of the rectangular matrix, and bits-output from the rectangular matrix with pruning [2]. 

The parity blocks are generated with the same convolutional encoder, and 3 tail bits are generated from the FEC 
encoder states [2]. 

The encoder outputs are collected in the channel coded bit buffer according to Figure 7. 



MSD+CRC taih taib Parity 1 ptaih Parity 2 ptaib 



Figure 7: Channel coded bit buffer 



5.1.3.3 



HARQ for MSD messages 



The applied HARQ scheme can create eight different redundancy versions (RV), rvQ . . . rvl, from the channel coded bit 
buffer. Each one of the RV consists of a subset of 1380 bits from the channel coded bit buffer. rvO, rv2, rv4, and rv6 
contain the entire MSDh-CRC part of the channel coded bit buffer. The maximum code rate of the coding scheme is 
r^ff- 0.83 since the MSD and CRC are 1 148 bit altogether. The redundancy is increased with every further transmission 
ofRVs. 

The generation of different redundancy versions of the MSD from the above FEC encoded bitstream is defined in ROM 
tables and can be found in 3GPP TS 26.268 [2]. 
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5.1.4 Modulation 

The encoded binary data stream bits bj are grouped into symbols. Each symbol d : carries 3 bits of information and 
modulates one basic uplink waveform which corresponds to one modulation frame. 

There are two modulator modes, a fast modulator mode and a robust modulator mode. Under normal conditions, a 
transmission is successful when applying the fast modulator mode. The robust modulator mode serves as a back up 
solution if a transmission fails in unusually difficult environments. The modulator modes merely differ by symbol 
duration, i.e., the length of the modulation frames, which is 2 ms for the fast modulator mode and 4 ms for the robust 
modulator mode. In terms of samples this is 16 samples for the fast modulator mode and 32 samples for the robust 
modulator mode at 8 kHz sampling rate. Therefore, a speech frame accommodates 10 modulation frames (containing 10 
symbols, or 30 bit) for the fast modulator mode and 5 modulation frames (5 symbols or 15 bit) for the robust modulator 
mode. Hence, the modulation data rates are 1 500 bit/s and 750 bit/s, respectively, not accounting for muting gaps and 
synchronization frames. 

The uplink waveform is determined by the basic uplink waveform p^^ (n) , which is 

p^^(n) = (0, 0, 0, 40, -200, 560, -991, -1400, 7636, 15000, 7636, -1400, -991, 560, -200, 40) 

for the fast modulator mode (n = 0, . . ., 15) and 

p^^(n) = (0, 0, 0, 0, 0, 40, -200, 560, -991, -1400, 7636, 15000, 7636, -1400, 
-991, 560, -200, 40, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) 

for the robust modulator mode (n = 0,...,31). These values are given with respect to a signed 16-bit signal 
representation. The mapping between the symbol d ,- and the uplink waveform is given by a cyclic right-shift of k 

samples, denoted by (p —> k) , and the sign q of the basic uplink waveform p^i^in) . Table 1 details this mapping. Note 

that the position (cyclic shift) of the waveform carries two bits of information while the sign of the waveform adds 
another bit of information. Figure 8 illustrates the slot structure of both modulator modes. It represents a particular 
example symbol sequence in an abstract way by neglecting the actual shape and signs of the waveforms. The large bars 
indicate the maxima of the basic uplink waveforms according to the example symbols whereas the small ones indicate 
the other potential maximum positions. 

Table 1 : Symbol modulation mapping for uplink 



Symbol 


uplink waveform 
fast modulator mode 

WuL(n) = q-{p(n)^k) 

(n=0,...,15) 


uplink waveform 

robust modulator 

mode 

iVuL(n) = q-{p(n)^k) 
(n=0,...,31) 


d^ 


b: 


sign^ 


cyclic shift 
k 


sign? 


cyclic shift k 





000 












1 


001 




4 




8 


2 


010 




8 




16 


3 


oil 




12 




24 


4 


100 


-1 


12 


-1 


24 


5 


101 


-1 


8 


-1 


16 


6 


110 


-1 


4 


-1 


8 


7 


ill 


-1 





-1 
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Robust modulator mode; 



modulation frame (4 ms) 



Fast modulator mode: 



modulation frame (2 ms) 



speech frame length (20 ms) 

Figure 8: Slot structure of uplink modulator 

5.1.5 MSD data frame format 

Each MSD data frame includes one encoded MSD message with CRC field, split up into multiple data fields. 

The MSD data frame forms the largest fraction of uplink data traffic and consists of three data fields, four muting gaps, 
and three synchronization fragments (see clause 5.1.6), arranged as given in Table 2a. 

Table 2a: MSD data frame format 



Pos. 


Fast modulator mode 


Robust modulator mode 


1 


1 frame of muting, Ml (20 ms) 


1 frame of muting, IVI1 (20 ms) 


2 


15 frames of modulated data, D1 (300 ms) 


30 frames of modulated data, D1 (600 ms) 


3 


4 frames of sync fragment, SI (80 ms) 


4 frames of sync fragment, SI (80 ms) 


4 


2 frames of muting, M2 (40 ms). 


4 frames of muting, M2 (80 ms). 


5 


15 frames of modulated data, D2 (300 ms). 


30 frames of modulated data, D2 (600 ms). 


6 


4 frames of sync fragment, S2 (80 ms) 


4 frames of sync fragment, S2 (80 ms) 


7 


2 frames of muting, IVI3 (40 ms) 


4 frames of muting, M3 (80 ms) 


8 


16 frames of modulated data, D3 (320 ms) 


32 frames of modulated data, D3 (640 ms) 


9 


4 frames of sync fragment, S3 (80 ms) 


4 frames of sync fragment, S3 (80 ms) 


10 


3 frames of muting, IVI4 (60 ms) 


3 frames of muting, IVI4 (60 ms) 


Sum 


66 speech frames (1320 ms) 


1 1 6 speech frames (2320 ms) 



5.1 .6 Synchronization signal and frame format 

The synchronization frame consists of the direct concatenation of: 

1) the synchronization tone .?,(«) ; and 

2) the synchronization preamble s (n) . Note that the synchronization preamble is not only used in the 

synchronization frame, but fragments thereof are also inserted into the MSD data frame for the purpose of 
synchronization tracking. 

The synchronization tone s, (n) consists of a sampled sinusoidal tone of frequency 500 Hz or 800 Hz, and of 64 ms 
duration. A frequency of 500 Hz is chosen to indicate that the fast modulator mode is to be applied and a frequency of 
800 Hz indicates that the robust modulator mode is used for the subsequent MSD frames. 
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The synchronization tone s, (n) is followed by synchronization preamble s p{n) . The synchronization preamble is a 

pulse sequence known at the receiver. The pulse sequence for the synchronization preamble has been chosen to 
optimize autocorrelation properties in order to allow a very reliable detection and delay estimation at the same time. The 
achieved accuracy of the delay estimation is typically exact by sample. 

The basis of the synchronization preamble i„ (n) is a PN sequence of length 15 that takes values of (1, 1, 1, 1,-1, 1,-1, 

1,1,-1,-1,1,-1,-1, -1). Each pulse has an amplitude of 20000 in a signed 16-bit signal representation. The pulse 
sequence is composed of 5 periods of this PN sequence. The outer periods (number 1 and 5) are inverted (i.e. all 
elements are multiplied with -1) and those parts that are common to the inverted and non inverted sequence are 
transmitted just once, see Figure 9. Figure 10 illustrates the resulting pulse sequence. 



^+++-+-++ — H ^+++-+-++ — + ^+++-+-++ — +- 



-+-+ — ++- 



-+-+ — ++-+++ 



pulse sequence constructed from 5 pn-sequences: 



I +"+ — ++-++++-+-++ — + ++++-+-++ — + ++++-+-+H + +-H ++-+++I 

Figure 9: Construction of pulse sequence for the sync preamble (+ := +1 and -:= -1) 
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Figure 10: Pulse sequence for generation of synchronization preamble 

In the pulse sequence, neighboring pulses are placed 22 samples apart to form the synchronization preamble, i.e. 
zero-padding of 21 zero samples between pulses is applied. In addition, 71 zero samples are placed before the first 
pulse. The resulting synchronization preamble has a duration of 71 + 69 + (68*21) = 1568 samples, or 196 ms. 

Both synchronization tone s, (n) and synchronization preamble i „ (n) can be stored in a ROM table to avoid 

computation at runtime. These tables can be found in 3GPP TS 26.268 [2], and they should serve as a reference of the 
synchronization signal.. 

The overall length of the synchronization frame is 13 frames or 260 ms. 

For the purpose of uplink synchronization tracking, fragments of the synchronization preample are inserted into the 
MSD data frame (see Table 2a). A synchronization fragment consists of the last 576 samples of the synchronization 
preamble i „ («) , prepended by 64 zero-samples. A synchronization fragment is thus 640 samples or 80 ms long. 



5.1.7 



Multiplexing 



The multiplexer combines the synchronization frame and the MSD data frames to the effective transmit signal as in 
Figure 1 1 . 











MSD rvO 






















SF 


M1 


UL Data 1 


S1/M2 


UL Data 2 


S2/M3 


UL Data 3 


S3/M4 



Figure 1 1 : Uplink data format with multiplexing 
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5.1 .8 Uplink signal and retransmission 



The uplink signal starts with a synchronization frame (SF) which is succeeded by one or more MSD redundancy 
versions, e.g. MSD rvO, MSD rvl, MSD rv2, etc. as shown in Figure 12. 

MSD rvO is the first transmission of a full MSD message. MSD rvl represents the first retransmission, MSD rv2 the 
second retransmission, each with a different version of incremental redundancy (IR). Up to eight different versions of 
incremental redundancy are allowed (MSD rvQ . . . MSD rvl). 

In good channel conditions, the MSD should be successfully decodable after the reception of the first transmission, 
MSD rvO. 

The IVS transmitter stops transmitting when an ACK message is received on the downlink by the IVS receiver. 

If, after one transmission attempt (consisting of 8 RV transmissions), the MSD message is still not received correctly, 
the MSD transmission cycle is started again with one synchronization frame and MSD rvO, using the robust modulator 
mode. The PSAP receiver resets the IR combining buffer after 8 received MSD messages, switches the demodulation 
mode, and restarts combining again. 



SF MSD rvO MSD ri/l MSD rv2 



time 
Figure 12: Uplink signal format 

The generation of different redundancy versions of the MSD is defined in ROM tables and can be found in 3GPP 

TS 26.268 [2]. 



5.1 .9 Additional signal format for push mode 

If the IVS is to issue the request for MSD transmission, it reuses the downlink signal format according to clause 6. 1 . 
The message used for the data part is reproduced in Table 2b. The modulated data may be precomputed and stored in 
the IVS ROM. Several such messages are transmitted before an IVS state change triggers the MSD transmission, or a 
timeout occurs. 

Table 2b: Uplink push message encoding 



Message 


Binary 
representation 


BChH encoder output, b, 
(hexadecimal)* 


push (IVS initiation message) 


0011 


DBE 9397 9461 07EA 



see clause 6.1 for encoding scheme 



5.2 IVS receiver 

The IVS receiver demodulates and decodes feedback messages (START, NACK, link-layer ACK, and higher-layer 
ACK) from the PSAP. It starts the IVS transmitter after detecting a request message (the START trigger) for MSD data 
transmission on the downlink. The different blocks of the IVS receiver are shown in Figure 13. 
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Figure 13: IVS receiver blocic diagram 



5.2.1 Synchronization detector/tracker 

For support of the synchronization/detection function, each synchronization frame includes two parts, which are 
denoted as synchronization tone and synchronization preamble as described in clause 5.1.6. 

NOTE: The downlink synchronization frame is identical to the uplink synchronization frame (except that the 

downlink only uses a frequency of 500 Hz for the synchronization tone), however, the data frame formats 
are different in uplink and downlink. 

The synchronization detector/tracker has three main functions: 

1) Scan the input signal and identify the start of an eCall data transmission. The result of this operation is a 
synchronization detection flag which indicates whether or not eCall data transmission has been detected. 



2) Determine the timing of the data frame. The result of this operation is timing information from which the 
location of the data burst in the input signal can be calculated at sample resolution. 

3) Continuously check and track the data frame timing. Based on the subsequently received synchronization 
frames, the validity of the data frame timing is checked. In case the check fails, the synchronization tracker tries 
to identify a new valid data frame timing. 

To avoid false detection of an eCall data transmission in the IVS receiver, the synchronization detector evaluates three 
consecutive sync frames. It sets the detection flag DF = 1, only if the same timing information is detected in three 
successively detected sync preambles. This feature is also required to prevent misdetection of the START message and 
to keep the synchronization failure rate at virtually zero. 

The synchronization preamble sequence in Figure 10 is constructed to have good autocorrelation properties for optimal 
detection as shown in Figure 14. 
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Figure 14: Autocorrelation properties of pulse sequence of Figure 10 



The synchronization algorithm acquires the delay value by checking the correctness of the distance between the five 
correlation peaks. A preamble is considered detected if either the pair of peaks (2, 4) or the pair of peaks (1,5) exhibit 
correct distances from each other, provided that they either fulfil certain amplitude constraints (the amplitude 
differences shall not differ by more than a factor of 3 and their average shall not be less than half of the global maximal 
sync filter output since first activation of the synchronization detector), or one additional peak is identified. 

To distinguish between higher-layer ACK message and link-layer ACK messages on the downlink, an inverted sync 
pulse sequence precedes the higher-layer ACK messages. The synchronization detector determines the signs of the 
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autocorrelation pulses independently from the absolute peak values and peak distances. The correlation peak signs are 
used to determine whether the incoming feedback message is a link-layer ACK or higher-layer ACK message. If an 
inverted sign of autocorrelation pulses is detected right from the beginning of uplink and/or downlink transmissions, the 
synchronization detector assumes that a signal inversion is occurring on the transmission path. In this case, all received 
PCM samples are multiplied by -1 on the affected link for the remainder of the MSD transmission. 

Because feedback messages are transmitted continuously on the downlink, it is usually sufficient for the IVS receiver to 
perform the synchronization only once per MSD. This means, synchronization can be locked once an eCall data 
transmission has been detected and the timing information has been computed. Nevertheless, there exist rare scenarios 
that may require a resynchronization due to lost synchronization, e.g. because of an adaptive jitter buffer, or an analog 
PSTN line with sampling clocks drifting between transmitter and receiver. Therefore, the correctness of the 
synchronization is checked continuously (referred to as "Sync Check") by evaluating the existence of correlation peaks 
at the expected peak positions for any of the feedback messages. The data part of a message is ignored if none of the 
five peaks is detected. 

A sync tracking feature is also implemented which re-uses the original synchronization algorithm and evaluates the 
cross-correlations of the incoming signal and the known synchronization sequence in a certain interval around the 
previously expected delay position . The width of this serach interval can be set as a parameter of the synchronization 
function, with a maximum value of +1- 480 samples in the IVS sync tracker. Note that the cross-correlation search can 
be efficiently implemented by FIR filtering. 

If no valid delay position can be identified 8 times in a row, the IVS resets itself. 

5.2.2 Timing Unit 

The timing unit adjusts the timing of the received signal for the following processing stages according to the timing 
information obtained by the synchronization detector/tracker. 

5.2.3 De-multiplexing 

The de-multiplexer removes the muting and synchronization signals from the input data stream. 

5.2.4 Data demodulation and FEC decoding 

The data demodulator and decoder on the downlink are represented by a single correlator matched directly to the 
modulated downlink waveforms. The received waveform is correlated to each of the stored waveforms and a maximum 
likelihood decision on the feedback message, msg, is made. 

479 

metricik) = ^ pcm _ data{i) * dlPcmMatch(k)(i), k = 0,1,2,3 

msg = arg max metric(k) 

k 

Since only a very small number of different data messages (see Table 3) is used on the downlink, the entire expected 
signal patterns can be stored at the IVS receiver. These patterns have a length of 480 samples each (corresponding to 60 
ms, which is the length of modulated feedback messages). In the demodulator/decoder the cross-correlation between the 
received signal and the stored pattern for each possible transmit message is calculated, and a decision for a message is 
made according to individual correlation thresholds. If synchronization has detected a message, but the demodulator 
threshold is not reached for either of the valid messages, the message is marked as unreliable and ignored in the case of 
lower-layer ACK or NACK. In case of START, the first six unreliable messages are ignored, but subsequent unreliable 
messages are not distinguished from reliable ones any more. For higher-layer ACK, unreliable messages contribute with 
a lower weight to the detection decision. The compressed higher-layer ACK is considered as successfully received if 
three consecutive messages (irrespective of reliability), or two reliable, consecutive messages, are detected with 
identical data. 



5.2.5 Message handler 



This function activates the appropriate functions in the IVS modem according to the message received. After 
synchronization is locked, the IVS transmitter is activated to send MSD data to the PSAP once a START message has 
been received. During an ongoing transmission, a sequence of least 3 reliable START messages is required to restart 
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the MSD transmission from the IVS to the PSAP. As long as only NACKs are received, MSD transmission continues 
with incremental redundancy. A successfully received link-layer ACK or a higher-layer ACK simply instruct the IVS 
transmitter to stop transmission. Also, if the Sync Check fails to track the preamble, the IVS transmitter is reset to idle 

state. 



6 Functional description of the PSAP data modem 

This clause describes the different functions of the PSAP data modem. 



6.1 



PSAP transmitter 



The PSAP transmitter generates the signal sent on the downlink. This signal is required to control the transmission of 
the MSD message on the uplink. The different blocks of the PSAP transmitter are shown in Figure 15. 
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Figure 15: PSAP transmitter blocl< diagram 

6.1 .1 Message encoding 

The PSAP transmitter is designed to send up to 16 different link- layer feedback messages to the IVS. Three of them are 
used currently as follows; 

1) START signal, i.e. the signal that triggers start of the IVS MSD transmission. 

2) NACK, i.e. negative acknowledgement upon CRC check failure. 

3) ACK, i.e. positive acknowledgement upon CRC check success. 

A fourth link-layer message is defined for exclusive use in the higher-layer ACK message (see Table 3). 

6.1.2 BCH encoding 

The link-layer feedback message code is error protected by a shortened (60, 4) BCH block code which is derived from a 
(63, 7) BCH code. The messages and their encoded representations are shown in Table 3. 

Table 3: Downlinit message encoding 



Link-layer feedback 
message 


Binary 
representation 


BCH encoder output, b/ 
(hexadecimal) 


START trigger 


0000 


A72 F298 41 FA B376 


CRC flag = 1 (ACK) 


0001 


4C4 1FD6 6ED2 7179 


CRC flag = (NACK) 


0010 


97A 8C41 FAB3 7693 


reserved 


0011 


DBE 9397 9461 07EA 


Not used 


01 00 to 1111 
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The binary representations of the link-layer feedback messages defined in Table 3 are re-used for the compressed 
higher-layer ACK (HL-ACK) message, in which four data bits (i.e., two of the binary link-layer message 
representations) are transmitted in a different feedback message format (see clause 6. 1 .4) 



6.1.3 



Modulation 



The encoded binary data stream bits bj are grouped into symbols. Each symbol d ,- carries 4 bits of information and 
modulates one basic downlink waveform. 

The duration of the downlink waveform is 4 ms or 32 samples at 8 kHz sampling rate. Therefore 5 modulation frames 
correspond in length to one speech frame. Each modulated waveform carries one symbol of 4 bits of binary information 
and the modulation data rate is 1 000 bits/s for the downlink transmitter (modulation data rate for EEC -encoded bits, not 
considering muting gaps and synchronization frame). 

The basic downlink waveform /^^^ (n) is defined for n = 0, ... ,3 1 as follows: 



poL(n) = (40, -200, 560, -991, -1400, 7636, 15000, 7636, -1400, -991, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 



560, -200, 40, 
0, 0, 0) 



0, 0, 



Table 4 describes the symbol modulation mapping between symbol and the downlink waveform. The downlink 
waveform is derived from the basic downlink waveform /^o/^fn) by a cyclic right-shift by k samples, denoted by 
(p —> k) , and multiplication with a sign q. 

Table 4: Symbol modulation mapping (downlink) 



Symbol 


Downlink waveform 
(n=0,...,31) 


d^ 


b, 


sign q 


cyclic shift k 





0000 







1 


0001 




4 


2 


0010 




8 


3 


0011 




12 


4 


0100 




16 


5 


0101 




20 


6 


0110 




24 


7 


0111 




28 


8 


1000 


-1 


28 


9 


1001 


-1 


24 


10 


1010 


-1 


20 


11 


1011 


-1 


16 


12 


1100 


-1 


12 


13 


1101 


-1 


8 


14 


1110 


-1 


4 


15 


1111 


-1 






Since there are only few messages for the downlink and the modulated waveform for each message is relatively 

short (480 samples), the modulated downlink waveforms are stored in ROM tables to save computation 
complexity at runtime. The downlink waveforms can be found in 3GPP TS 26.268 [2]. 

6.1.4 Downlink signal 



6.1.4.1 



Link-layer feedback messages 



Every downlink message starts with a synchronization frame (as defined in clause 5.1.6) and continues with a feedback 
frame. Eor the link-layer control messages, the feedback frame consists of a single DL-Data field surrounded by muting 
periods as follows: 



£75/ 



3GPP TS 26.267 version 9.2.0 Release 9 23 ETSI TS 1 26 267 V9.2.0 (2011 -01 ) 

1) 3 frames of muting, Ml (60 ms). 

2) 3 frames of modulated data, DL-Data (60 ms). 

3) 1 frame of muting, M2 (20 ms). 

Each DL-Data field includes one of the three types of link-layer messages in a block-encoded representation as 
described in clause 6. 1 .2. 

6.1 .4.2 Higher-layer acknowledgement messages 

For the higher-layer acknowledgement messages, the synchronization frame defined in clause 5.1.6 is inverted (i.e., 
each sample is multiplied with -1). The feedback frame consists of two DL-Data fields preceded by a muting period as 
follows: 

1) 1 frame of muting. Ml (20 ms). 

2) 3 frames of modulated data, DL-Data 1 (60 ms). 

3) 3 frames of modulated data, DL-Data 2 (60 ms). 

Each DL-Data field includes one of the four types of block-encoded two-bit binary message representations as 
described in clause 6. 1 .2. The feedback frame for higher-layer acknowledgement messages therefore transports four 
information bits for use by the higher-layer application protocol (HLAP). These information bits can be used to satisfy 
the eCall requirements [1], e.g. to clear down the call. 

6.1 .4.3 Handling of downlink messages 

The PSAP transmitter retransmits the START message multiple times until it has detected the uplink synchronization 
frame. Upon detection of the synchronization frame, the PSAP transmitter sends a series of NACK messages, until a 
successful CRC check of the MSD message is obtained. After successful MSD detection, the PSAP transmitter sends 
link-layer ACK messages and/or the higher-layer ACK (HL-ACK). This operation is illustrated in Figure 16. 



SF ISTART I SF [START I ■ ■ ■! SF | NACK | SF | NACK I- ■ ■ 



time 



SF I ACK I SF I ACK I- ■ -ISF'M) I HL-ACK |SF*M)I hl^ackI 



Figure 16: Downlink signal format 

If the PSAP transmitter fails to obtain uplink synchronization, it will not start transmitting NACK on the downlink. 
Instead, START messages are repeated. The IVS awaits the reception of a NACK after transmission of the first uplink 
synchronization frame. If instead repeated START messages are received, it interrupts the current MSD transmission 
attempt and starts with a new synchronization frame and MSD rvO. If the receiver is not able to decode the message 
successfully within 8 redundancy versions or if the Sync Tracker indicates that synchronization has been lost on the 
uplink, it asks the IVS to restart the transmission with a new synchronization frame and MSD rvO. This is achieved by 
switching from NACK to START messages. 

The repetition of START messages by the PSAP (in case it does not obtain any uplink synchronization) continues until 
the PSAP modem is manually switched off by the operator. An automatic PSAP timeout mechanism should be added to 
the PSAP implementation if this behaviour is not desirable. The PSAP timeout mechanism is not part of this 
specification. 

6.1.5 Synchronization 

Synchronization signals for the PSAP transmitter are as described in clause 5.1.6, except that a value of 5000 is added 
to the PN sequence pulses (i.e., the resulting pulses have amplitudes of 25000 and -15000), and the original zeroes are 
replaced by samples with a value of 12000. 
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For higher-layer acknowledgement messages, the synchronization frame defined above is inverted (i.e., each sample is 
multiplied with -1). 

6.1.6 Multiplexing 

The multiplexer combines synchronization, muting and feedback frames to form the downlink signal for the PSAP 
transmitter. 



6.2 



PSAP receiver 



The PSAP receiver demodulates the MSD message from the IVS and checks the integrity of the received MSD by 
evaluating the CRC field. The different blocks of the PSAP receiver are shown in Figure 17. 
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Figure 17: PSAP receiver blocit diagram 

The PSAP receiver continuously monitors traffic from the speech decoder in idle or standby state. When the PSAP 
receiver is in idle state, speech from the speech decoder passes through as in normal voice call. 

Once an eCall sync burst is detected, the PSAP transitions out of idle state and the speech path to audio out is muted. 

6.2.1 Synchronization detector/tracker 

Basically, the uplink synchronization detector/tracker works as described in clause 5.2.1. Some differences are given in 
the following. 

The detection of a single synchronization preamble is sufficient to trigger the PSAP. A Sync Observer checks the 
received signal for another 10 speech frames after a preamble has been detected. This is to ensure that synchronization 
does not find a more reliable preamble, which would mean that the previous detection would have been a false detection 
(wrong delay value). In case synchronization does find a better preamble it restarts the reception of the MSD. 

The Sync Check function continuously checks the validity of the identified delay value, based on the subsequently 
transmitted uplink synchronization fragments. If the delay value is found to be invalid, the Sync Tracker searches for a 
new valid delay value within a pre-defined search window. The maximum setting for the search window at the PSAP 
receiver is +/- 240 samples. If, after an invalid delay value, the Sync Tracker cannot identify a new valid delay value 
for a certain number of subsequent synchronization fragments (default value is four unsuccessful tracking attempts), it 
resets the PSAP transmitter in order to re-initiate the MSD transmission by sending START messages to the IVS. 

A tone detector based on a DFT evaluation at the two reference frequencies is used to evaluate the frequency of the sync 
tone. If the frequency can be detected reliably, then this decision is taken to decide on which modulator is used for 
demodulation. If a reliable detection is not possible, the fast modulation scheme is chosen if it is the first time that a 
preamble has been detected successfully while receiving the current MSD. Otherwise, the robust demodulator is chosen. 

6.2.2 Timing Unit 

As described in clause 5.2.2. 
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6.2.3 De-multiplexer 

As described in clause 5.2.3. 

6.2.4 Data demodulator 

The data demodulator is represented by a correlator matched to the modulated waveform applied by the data modulator 
of the IVS transmitter. Specifically, correlations for all possible symbols are calculated: 

n 

r{i) = 2^ulPulse(j)*ulPulseMatch(i)(j) 

r(/ + 4) = -r(3-0, / = 0,1,2,3 

where n =15 for the fast modulation mode and n =31 for the robust modulation mode. 

The correlation values r(i) are then normalized by their variance and subtracted by a mean value to be converted to 
soft symbols for the H ARQ FEC decoder [2] . 

6.2.5 HARQ FEC decoder 

The HARQ decoder combines the demodulated and deinterleaved data signal with previously transmitted redundancy 
versions. For this operation it applies a two stage rate matching scheme and performs turbo decoding of the combined 
soft-information. 

To speed up the MSD reception in adverse transmission conditions, the HARQ decoding is performed for partially 
received messages, starting from the second redundancy version, rvl. Decoding is then attempted after reception of 
each of the three data parts of the MSD frame (see clause 5. 1.5). The decoding attempts based on partial messages is 
beneficial since, in many cases, the correct MSD can be decoded already after the incremental redundancy contained in 
the first data part Dl of rvl. Figure 18 summarizes the decoder algorithm. 

After MSD data bits are decoded, a descrambling operation as described in clause 5.1.2 applies. 
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Figure 18: Turbo decoder 



6.2.6 CRC handling 



This function performs a CRC check and outputs a CRC flag. The CRC flag triggers transmission of an ACK or NACK 
message by the PSAP transmitter. 

6.2.7 Push mode - push message detector 

In push mode the PSAP receiver starts monitoring the incoming signal immediately after the call has been established. 
For Xhc push message (IVS initiation sequence) detection, it applies the same receiver as described in clause 5.2. A push 
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command is considered detected if two correct sync preambles have been detected and a subsequent push message (see 
Table 2b) has been identified. 



7 Transmission protocol and error handling 

This clause describes the employed eCall transmission protocol in normal operation, and its handling of transmission 
errors. 



7.1 Normal operation 



The operation of the eCall data transmission in the "normal" non-erroneous case works as outlined on a high level in the 
previous clauses. 

Upon request by the operator or by the IVS push message, the PSAP transmitter starts sending START messages. The 
IVS receiver shall detect the synchronization preambles that are transmitted along with the START messages and obtain 
synchronization. This enables the IVS receiver to demodulate and detect the START messages. The PSAP transmitter 
continues sending START messages to the IVS at this stage. 

Upon detection of the START message, the IVS starts the transmission of the first MSD message with incremental 
redundancy version rvQ which is preceded by a synchronization frame. The PSAP receiver shall detect the 
synchronization frame and obtain exact synchronization on the synchronization preamble. The PSAP receiver is then 
enabled to demodulate the MSD and to decode it. 

As soon as the PSAP receiver has obtained synchronization, it changes the PSAP to NACK message transmission and 
continues sending this message repeatedly. The IVS transmitter then should detect the NACK messages. The IVS 
continues sending MSD data. When transmission of the MSD message with rvQ has been completed, the IVS 
transmitter continues sending the next redundancy version rvl of the same MSD, and so on. 

The PSAP receiver, after demodulation of the full MSD with rvO, performs a CRC check. If the CRC check fails, the 
PSAP receiver continues sending NACK messages. If the CRC check succeeds, the PSAP transmitter changes the 
message to the link-layer or higher-layer ACK message. It is up to higher-layer protocol requirements whether link- 
layer and/or higher-layer ACK messages are transmitted. From a modem protocol perspective, at least five ACK 
messages of one type (either link-layer or higher-layer) shall be transmitted consecutively for security. No higher-layer 
ACK message shall preceed a link-layer ACK message, and no link-layer ACK message shall succeed a higher-layer 
ACK message. The IVS receiver should detect an ACK of one particular type (link-layer or higher-layer) and then stop 
the IVS transmitter sending the MSD. 



7.2 Abnormal operation 



This clause describes some abnormal scenarios which may occur due to severe signal distortion on the transmission 
channels and which need to be handled by the overall transmission protocol to avoid any deadlock situations. This 
description of abnormal scenarios is not necessarily exhaustive. 

Table 5 lists potential abnormal scenarios together with the measures implemented against it in the eCall solution. In the 
table, the reference numbers refer to the following case categorization: 

1 . IVS error cases 

1.1 Sync error 

1.1.1 No successful synchronization 

1.1.2 Successful synchronization although no sync frames were sent 

1.1.3 Successful synchronization, but wrong timing 

1 . 1 .4 Lost synchronization 

1 .2 Sync detected, correct timing, false detection of PSAP messages 
1 .2. 1 Errors at transmission of START messages 
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1.2.1.1 START message sent, no downlink message detected 

1 .2. 1 .2 START message sent, NACK detected 

1.2.1.3 START message sent, ACK detected 

1 .2.2 Errors at transmission of NACK messages 

1.2.2.1 NACK message sent, no downlink message detected 

1.2.2.2 NACK message sent, START detected 

1 .2.2.3 NACK message sent, ACK detected 

1 .2.3 Errors at transmission of ACK messages 

1 .2.3. 1 ACK message sent, no downlink message detected 

1.2.3.2 ACK message sent, START detected 

1 .2.3.3 ACK message sent, NACK detected 
2. PSAP error cases 

2.1 Sync error 

2.1.1 No sync preamble detected 

2.1.2 Sync preamble detected, but wrong timing or false detection 

2.1.3 False evaluation of sync tone 

2.2 Sync detected, correct timing, false detection of MSD messages 

Table 5: List of potential abnormal cases and protocol solutions 



Ref# 


Scenario 


Error description 


Error handling 


Comments 


1.1.1 


IVS receiver does not 
detect the sync frames or 
gets different delays from 
subsequent preamble 
detections. 


MSD message will 
never be sent 


Start message is sent 
a defined number 
times 


If the start message is not 
detected within a defined 
time, the PSAP goes back 
to idle state. In this case 
another attempt could be 
started manually by the 
PSAP operator. 


1.1.2 


IVS receiver detects equal 
sync frames while none 
were sent. 


Sync false alarm 


Sync Check verifies 
the validity of the sync 
continuously and 
resets the IVS if 
necessary. 


Synchronization at the IVS 
has been designed such 
that the probability of this 
error is negligibly small 
(virtually zero). 


1.1.3 


IVS receiver detects sync 
frames incorrectly and 
triggers nevertheless. 


START message is 
usually not detected 
correctly and IVISD 
message will never 
be sent 


Same as #1.1.2 


Same as #1.1.2 


1.1.4 


Synchronization gets lost 
due to some abnormal 
channel conditions 


Feedback messages 
are skipped due to 
Sync Check and 
unsuccessful Sync 
Tracker 


Same as #1.1.2 


The Sync Tracker usually 
avoids this situation (e.g., 
due to adaptive jitter 
buffers or in the unlikely 
case of a handover) 


1.2.1.1 


In-sync, but detection of 
START messages fails 


If START message is 
never detected, same 
as 1.1.1. 


START message is 
repeated a defined 
number of times. This 
decreases the 
likelihood of this case 
to almost zero 





£75/ 



3GPP TS 26.267 version 9.2.0 Release 9 



28 



ETSI TS 126 267 V9.2.0 (2011-01) 



Ref# 


Scenario 


Error description 


Error handling 


Comments 


1.2.1.2 


In-sync, instead of a 


IVISD message is not 


PSAP always 






START message a NACK 


sent if transmission 


transmits more than 






is detected 


has not yet started. If 
a transmission is 
ongoing, it will not be 
restarted although 
the PSAP would want 
the IVS to restart. 


just one START 
message. A NACK 
before the first START 
message is ignored 




1.2.1.3 


In-sync, instead of a 


MSD message is not 


PSAP always 






START message an ACK 


sent if transmission 


transmits more than 






is detected 


has not yet started. If 
a transmission is 
ongoing, the IVS 
could terminate the 
transmission 
erroneously 


just one START 
message. An ACK 
before the first START 
message is ignored. If 
the transmission is 
terminated, the PSAP 
operator could 
retrigger the 
transmission of the 
MSD. 




1.2.2.1 


In-sync, NACK message 




NACK messages are 


IVS behaviour does not 




is not detected 




repeated until the 
correct MSD is 
received 


change in this case 


1.2.2.2 


In-sync, instead of a 


MSD transmission 


Only after a 


The probability of 




NACK message a START 


may be interrupted 


successive reception 


subsequent erroneously 




message is detected 


and restarted 


of three START 
messages the MSD 
transmission is 
restarted 


detected START 
messages is very low. 


1.2.2.3 


In-sync, instead of a 


IVS stops MSD 


At least two ACK 


The probability of the 




NACK message an ACK 


transmission before 


messages need to be 


subsequent erroneously 




is detected 


PSAP has detected 


detected subsequently 


detected ACK messages 






It. 


in order to stop 
transmission at the 
IVS. PSAP operator 
could retrigger the 
transmission of the 
MSD. 


is very low. 


1.2.3.1 


In-sync, ACK message is 


Results in prolonged 


ACK messages are 


Not a problem as long as 




not detected 


MSD transmission 


sent several times 


only few ACKs are 
missed. 


1.2.3.2 


In-sync, instead of a ACK 
message a START 
message is detected 


Same as 1.2.2.2 


Same as 1.2.2.2 




1.2.3.3 


In-sync, instead of a ACK 
message a NACK is 
detected 


Same as 1.2.3.1 


Same as 1.2.3.1 


Same as 1.2.3.1 


2.1.1 


No sync frame detection 


PSAP misses the 
MSD 


The PSAP continues 
sending START 
messages to the IVS 
until it detects a sync 
preamble. The IVS 
restarts transmission 
of the MSD with sync 
frame when it 
continuously receives 
START messages 
from the PSAP. 
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Ref# 


Scenario 


Error description 


Error handling 


Comments 


2.1.2 


PSAP receiver detects a 
sync frame while none 
was sent 


Sync frame false 
alarm, PSAP tries to 
decode data, but 
fails. 


After having failed the 
detection of a valid 
sync delay in 
subsequent sync 
frames, of after an 
unsuccessful 
reception of the MSD, 
the PSAP will ask the 
IVS to resend the 
MSD by transmitting 
START messages 
again. 


Introduces a delay in MSD 
transmission 


2.1.3 


Sync tone evaluated 
incorrectly 


Wrong modulator 
mode used to 
demodulate the MSD 


If there are doubts 
about the reliability of 
the tone detection, the 
PSAP uses the fast 
modulator mode for 
the first trial of 
demodulating the 
MSD (first set of 8 
RVs) and the robust 
modulator mode 
otherwise. 


This assumption about the 
modulator mode will be 
incorrect only if the IVS 
completely fails to 
evaluate many feedback 
messages, which is very 
unlikely. 


2.2 


Sync detected, correct 
timing, false positive 
detection of MSD 
messages 


CRC gives incorrect 
result 




Very unlikely 



7.3 PSAP and IVS protocol state models 

The state model of the PSAP is shown in Figure 19. 
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ACjKcnt 
fulfilled 



otherwise 



Figure 19: State model of the PSAP 

The state model of the IVS is shown in Figure 20. 
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START message detected 



LL ACK messages detected 



Reception of 



LL-ACK / HL-ACK 

messages 

(depending on configuration) 



otherwise 




Sync check failure 



occurs B times in a row 



Sync check failure 



occurs 8 times in a row 



otherwise 



Figure 20: State model of the IVS 
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Annex A (informative): 

eCall Performance Requirements/Objectives and Design 

Constraints 

Minimum performance requirements for non-bitexact implementations of the eCall modems, as well as exact 
performance figures of the bit-exact implementation, are given in a separate Conformance Testing document. 

The following is reproduced for information form the permanent document "eCall Performance Requirements / 
Objectives and Design Constraints", for eCall Phase 2. 

A.1 Definitions 

Performance Requirements shall be met by an eCall candidate, otherwise it is excluded from the selection. 

NOTE: The Performance Requirements include all service requirements. 

Performance Objectives provide no hard limits, but allow ranking of candidates according to defined criteria. 

Design Constraints provide upper limits (requirements and objectives), e.g. on algorithmic complexity. 

Selection Checking of candidate solutions against the Performance Requirements and Design Constraints, and ranking 
of candidates based on Performance Objectives, after which the highest-ranked candidate is selected. 

The eCall Protocol is the overall application-layer protocol between the IVS and PSAP. The selected candidate will 
provide data transport ("MODEM") for the eCall procedure. However, the application-layer of the eCall procedure is 
out of the scope. 



A.2 Performance Requirements 



The following text defines point by point the (Service) Performance Requirements for an eCall candidate. They have 
been taken directly from 3GPP TS 22.101 [1]. 

NOTE 1: 3GPP TS 22.101 [1] has been modified in the meantime to version V8.8.0. The changes introduced have 
been evaluated. They have no influence on the selection phase for eCall. 

NOTE 2: For the sake of the selection procedure, the candidate shall provide means for automatic retransmission. 
This is however not necessarily the final eCall Protocol. 

1 . The data may be sent prior to, in parallel with, or at the start of the voice component of an emergency call. 
NOTE 3: In-band data can not be sent prior to the point in time when the voice channel is established end-to-end. 

This requirement does not require additional interpretation. 

2. Should the PSAP request additional data then this may be possible during the established emergency call. 
This service requirement is considered in the selection as follows: 

"The eCall candidate algorithm shall allow the PSAP to request additional data at any time during the established 
emergency call." 

3. The realisation of the transfer of data during an emergency call shall minimise changes to the originating and 
transit networks. 

This service requirement is considered in the selection as follows: "The introduction of the eCall data transfer 
feature should have minimal (ideally no) impact on any existing mobile and transit network (in Europe), i.e. it 
should not require (major) changes nor impose (major) restrictions to future evolutions of the networks." 

4. Both the voice and data components of the emergency call shall be routed to the same PSAP or designated 
emergency call centre. 
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NOTE 4: In-band data can not be routed somewhere other than the voice channel it uses. 
This service requirement does not need to be considered in the selection. 

5. The transmission of the data shall be acknowledged and if necessary data shall be retransmitted. 

This service requirement is considered in the selection as follows: "In the case of errors detected by the candidate 
algorithm in the received data, a retransmission shall be requested by the candidate algorithm." 

6. A UE configured only to transfer data during emergency calls (e.g. eCall only UE) shall not generate signalling 
to the network besides what is needed to place an emergency call. 

This service requirement does not need to be considered in the selection. 

7. With the exception of the following specific requirements, considered necessary for the satisfactory operation of 
the eCall service, all existing TS12 emergency call requirements shall apply. 

This service requirement does not need to be considered in the selection. 

8. An eCall shall consist of a TS12 emergency call supplemented by a minimum set of emergency related data 
(MSD). 

This service requirement does not need to be considered in the selection. 

9. An eCall may be initiated automatically, for example due to a vehicle collision, or manually by the vehicle 
occupants. 

This service requirement does not need to be considered in the selection. 

10. The Minimum Set of Data (MSD) sent by the In vehicle System (IVS) to the network shall not exceed 140 bytes. 
This service requirement is considered in the selection as follows: "The whole 140 Bytes of the MSD shall be 
made available to the PSAP." 

1 1. The MSD should typically be made available to the PSAP within 4 seconds, measured from the time when end 
to end connection with the PSAP is established. 

This service requirement is considered in the selection as follows: "In optimal conditions (error-free radio 
channel, GSM FR codec and FR AMR 12.2 kbit/s mode) the eCall candidate procedure shall be able to transmit 
the whole 140 bytes of the MSD reliably within 4 seconds, measured from the time when the transmission from 
the IVS to the PSAP begins (after a trigger from the PSAP has been detected)." 

NOTE 5: See Performance Requirement 14. 

NOTE 6: "Reliability" is defined in the new Performance Requirement 15. 

NOTE 7: The Performance Objectives give additional guidelines for the performance under non-ideal channel 
conditions. 

12. Should the MSD component not be included in an eCall, or is corrupted or lost for any reason, then this shall not 
affect the associated TS12 emergency call speech functionality. 

This service requirement does not need to be considered in the selection. 

13. A call progress indication shall be provided to the user whilst the MSD transmission is in progress 
This service requirement does not need to be considered in the selection. 

In addition to the above Service Requirements, the following Performance Requirement shall apply to an eCall 
candidate solution. 

14. Installation of eCall equipment in a vehicle shall not affect an emergency call to a PSAP which is not upgraded 
to receive eCall data, i.e. the eCall candidate algorithm shall not send the eCall data unless the PSAP requests 
that it do so. 

15. The MSD shall be transmitted reliably to the PSAP. An MSD transmission is considered reliably terminated, if a 
cyclic redundancy check (CRC) of at least 28 bits, applied to the entire MSD, detects no errors. 

NOTE 8: If the CRC detects an error in the MSD, then an automatic retransmission shall be triggered, unless the 
PSAP decides to stop the transmission. 
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A.3 Performance Objectives 

Perfonnance Objective 1: The overall average transmission time should be as small as possible. 

Performance Objective 2: Under all test conditions, a candidate should be as good as or better than the proposed 
eCall_via_CTM* (see 3GPP TR 26.967 [4]) would be. 

NOTE: The objectives in the present document are intended as guidelines for designers of eCall solution 

candidates. The exact rules of candidate selection are specified in a separate document (PD3, "eCall 
Selection Test"). Objective 1 will be considered in the formulation of these rules. Objective 2 is intended 
only as a guideline and will not be considered in the formulation of the selection rules. 

Performance Objective 1 is explained in detail in the following: 

For any particular test condition (specified by speech codec plus radio channel error condition), the observed 
transmission time of the 140 bytes of the MSD may vary depending on the parameters of the channel simulation and the 
specific contents of the MSD. Therefore each MSD transmission may be regarded as one trial A; in a random experiment, 
where the observed transmission time, Tj., is the random variable of interest. For each particular test condition C, the 
MSD transmission is repeated with different, randomly generated MSD data for at least 100 times {k = 1, 2, ..., n, where 
n>100) to get enough statistical significance. 

To ensure a practical limit on the time required for testing a candidate, the observed value of Tj. must have a reasonable 
upper bound. This upper bound, tjjB, is fixed at a value of 200 seconds for one trial for all test conditions. Any value of 
r^-that is observed to be greater than ff/g will be classified as a transmission failure and will be assigned the value of ff/g. 

Each particular test condition C gives an observed sample distribution Tj, T2, ..., T„. The statistic of interest is the 
average value, jUc = {Tj + T2+ ■■■ + T„) I n. 

The Figure of Merit (FoM) over all test conditions is calculated by unweighted averaging of /fc over all particular test 
conditions Ci, C2, ..., C„. A low Figure of Merit is - obviously - better than a higher Figure of Merit. The candidates 
will be ranked by their Figures of Merit. 

The following assumptions are made for the measurement of T/,. 

1 . The starting time of the transmission with respect to speech codec audio frames is uniformly distributed. 

2. The channel error condition is modelled by an error pattern obtained from offline simulations. The following 
radio conditions will be tested: 

OMSK Full Rate radio channel at C/I values of 1, 4, 7, 10, 13, 16 dB, and error free; with ideal frequency 
hopping, with the Typical Urban profile and with slow vehicle speed. These channel conditions will be 
applied in both directions (uplink and downlink) symmetrically. 

GMSK Full Rate radio channel at RSSI value -100 dBm with no other interferer. This channel condition will 
be applied in both directions (uplink and downlink) symmetrically. 

The following speech Codecs will be tested: GSM_FR and FR_AMR (12.2, 10.2, 7.95, 7.4, 6.7, 5.9, 5.15, 4.75 kbps). 
DTX will be enabled in both directions. 

Table A.l gives an allocation of Codec Conditions to radio conditions in order to reduce the test effort to the reasonable 
minimum. The detailed allocation is defined in PD3, the "Selection Test Plan" Permanent Document. 

Table A.1 
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3. It is assumed that the transmission in the wireHne part of the eCall uses PCM (G.71 1, A-law) without any further 
transcoding and with a fixed, pre-selected level setting. 

4. It is assumed that no acoustical echo is produced by the IVS and that therefore no Acoustic Echo Suppressor is 
applied in the network. 

5. It is assumed that no Hybrid Echo is produced by the PSAP connection and that therefore no Hybrid Echo 
canceller is applied in the network. 

6. The MSD will contain randomly generated data. (Each possible byte sequence is considered to be equally 
probable.) 

7. The round- trip delay between the IVS and PSAP is a randomly generated value in the range (200 ms, 220 ms). 



A.4 Design Constraints 



The candidate algorithm as implemented in the IVS should not have more than 10 times the complexity of CTM. 

The candidate algorithm as implemented in the PSAP should not have more than 20 times the complexity of 

CTM. 

The complexity is estimated by compiling the C-Codes under similar compiler conditions and then measuring 

the processing times. 

The candidate algorithm as implemented in the IVS should not require more than 20KB of data memory. The 
candidate algorithm as implemented in the PSAP should not require more than 40KB of data memory. 
The memory requirements are estimated by inspection of the C-Codes. 

The IVS modem shall not be dependent on knowledge of the UE (e.g. the speech codec being used and the radio 
channel conditions). 

The IVS modem shall not require changes in the UE. 

The PSAP Modem shall not be dependent on knowledge of the call path (e.g. the speech codec being used and 
the radio channel conditions, delay, transcoding, etc.). 
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